Geoserver 1.4 and earlier

The coordinate system declared in the SRS field, in the feature types, is used just for the capabilities and to declare the SRS in the GML outputs.
WFS requests do not perform any coordinate system transformation, return coordinates as such using the declared SRS, so there may be a mismatch, for example GeoServer can declare coordinates are in EPSG:4326 (lon/lat) and output coordinates whose value are well beyond -180/180.
WMS requests do transform from the native coordinate system (if declared inside the data) to the one specified in the GetMap request, ignoring the declared SRS.

Geoserver needs to know what Coordinate Reference System (CRS) are your data expressed in. This information is used to:

• compute the lat/lon data bounding box we need to expose in WFS and WMS capabilities documents, as well as the EPSG id
• reproject your data in both WMS and WFS 1.1 requests

Geoserver 1.5.0 and 1.5.1

When addding new data, Geoserver tries to inspect data headers looking for an EPSG id. The following applies:

• if data has a CRS with an explicit EPSG id, and the full CRS definition behind the ID is the same as Geoserver one, you'll have the feature type/coverage with an EPSG id already set.
• if data has CRS but no ID, you can use the "lookup CRS" button to make Geoserver perform an expensive lookup operation where data CRS is compared against each known CRS. If this succeds, an EPSG id will appear. The common case for a CRS that has no EPSG id is shapefiles and world image files whose .prj ancilliary file does contain a valid WKT string without the EPSG identifiers (these are optional).

If an EPSG id cannot be found, it means either your data has no CRS, or an unknown one:

• if your data has no native CRS information, you'll have to lookup by hand an EPSG ID using the list of known IDS, and declare id: Geoserver will make sure your data is handled as if the specified EPSG id was declared inside it (that is, the EPSG id is forced onto the data).
• If your data has an unknown CRS defined in it, you can handle the situation in two ways:
  • Declare manually another EPSG ID, data will be transfomred on the fly from the data CRS to the declared one before being served. With this solution, your data has a separate public face, that is, users will think the data CRS is the one declared, whilst instead inside data is handled in his native CRS.
  • Teach Geoserver about the CRS. Here is the guide about adding a custom CRS in Geoserver.

If you're wondering why we reproject on the fly from the unknown CRS to the declared one, it's because usually data has been produced by someone who knows about CRS, and thus the CRS is correct most of the time. At the same time, we have to declare an EPSG id becuase of OGC standards requirement, we can't just state we don't know. If you know your data CRS is wrong, fix it there, most of the time it's possible and not very complicated. If unsure on how to do it, ask on the Geoserver users mailing list for directions.

Geoserve 1.5.2 onwards

When addding new data, Geoserver tries to inspect data headers looking for an EPSG id. The following applies:

• if data has a CRS with an explicit EPSG id, and the full CRS definition behind the ID is the same as Geoserver one, you'll have the feature type/coverage with an EPSG id already set.
• if data has CRS but no ID, you can use the "lookup CRS" button to make Geoserver perform an expensive lookup operation where data CRS is compared against each known CRS. If this succeds, an EPSG id will appear. The common case for a CRS that has no EPSG id is shapefiles and world image files whose .prj ancilliary file does contain a valid WKT string without the EPSG identifiers (these are optional).

If an EPSG id cannot be found, it means either your data has no CRS, or an unknown one. Geoserver 1.5.2 has various option to deal with this case, that try to address some complains about the automated reprojection that was performed in 1.5.1:

• force the declared CRS, ignoring the native one. This is the right solution if it's known the original CRS is wrong.
• reproject from the native to the declared CRS. This is the right solution is the native CRS is correct, but cannot be matched to an EPSG number, so one states a special one for the sole purpose of representing the data in a well know and standard compliant code. The alternative is to add a custom EPSG code that matches exactly the native SRS.
• if your data has no native CRS information the only solution is to specify an EPSG code, that will be forced onto the data like in the first option.